-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch PianoKeyboard between Notated Pitch (effective pitch) and Playback Pitch (completed). #24784
Switch PianoKeyboard between Notated Pitch (effective pitch) and Playback Pitch (completed). #24784
Conversation
This PR should be ready for review now. I moved the EDIT: I tested without the -F option and it indeed preserves the setting across executions of MuseScore. |
src/engraving/dom/edit.cpp
Outdated
@@ -1587,7 +1587,7 @@ NoteVal Score::noteVal(int pitch) const | |||
|
|||
// if transposing, interpret MIDI pitch as representing desired written pitch | |||
// set pitch based on corresponding sounding pitch | |||
if (!style().styleB(Sid::concertPitch)) { | |||
if (!style().styleB(Sid::concertPitch) && configuration()->pianoKeyboardUseNotatedPitch().val) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we should do this check here. It might be preferable to move the setting back to notationConfiguration
and retrieve its value outside the engraving module (since I'd rather consider it UI logic than business logic) and pass it as a bool parameter to Score::addMidiPitch
and Score::noteVal
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't disagree with what you say at all, but I have trouble seeing any philosophical difference between the Display Concert Pitch setting and this new one as far as to whether they are business logic or UI. If we are going to move the new one, we should move the old one as well, and that may get into a rats' nest of refactoring. (You would know better than I whether it is a lot.)
Or maybe the noteVal
function should not be part of Score. But that seems like gets into even more refactoring.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say that the difference is the scope of these settings. Sid::concertPitch
is a score setting, and affects also how the score is typeset, i.e. really the content; pianoKeyboardUseNotatedPitch
is a UI setting, independent of the score, affecting only the behaviour of the UI.
There are absolutely a lot more opportunities for refactoring in the Score class and things around note input... but let's save that for different PRs!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I hope you will get to know me well enough that I sometimes when write out a counter argument, I then begin arguing against my own argument in my head and eventually convince myself that I was wrong. I think I get how Display Concert Pitch could be construed as business logic (perhaps because it controls engraving output) while there is no possibility of the input being so construed. So I will investigate your suggestion.
See also the recent discussion in #15594; the scope of the issue has been extended a little bit. Personally I prefer the two "use notated pitch" / "use sounding pitch" options over a single checkbox though, because with these options you really know what you are choosing from. I'll add that as a comment at #15594. |
The boolean (potentially) needs to be passed from three locations:
I am passing the boolean in from the latter 2 but not the 1st ( |
I agree that the UI should be in Preferences. I'll tackle that on a different commit, though it can be on this PR if you wish. I would like to nail down the PR as it was. |
Hm, adding a bool parameter Re. how to test: when you right-click the note input button in the toolbar, you get a menu where you can choose "realtime" note input mode. I've never studied how this works, but maybe the MuseScore 3 (!) handbook is useful: https://musescore.org/en/handbook/3/note-input-modes#realtime-auto Making the preferences changes in separate commits to this PR seems good to me. |
Given that Perhaps |
fd5ecbd
to
a2edd6f
Compare
Assuming the checks pass, it looks ready for review to me. (I've reviewed the cumulative file changes and they now all look as I intended them to.) The names have all been changed to match the new menu items and location of the menu. |
552f0d2
to
dfcb72d
Compare
…EngravingConfiguration to make it accessible in Score class.
…core, plus other codereview fixes.
dfcb72d
to
d44b99e
Compare
excellent suggestions both. update is posted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from that last thing, looks good to me!
they say naming is the hardest thing in programming. fixed it. |
There are only two hard things in Computer Science: cache invalidation and naming ... things. -- Phil Karlton There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. -- Leon Bambrick There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery -- Mathias Verraes there's two hard problems in computer science: we only have one joke and it's not funny. -- Phillip Scott Bowden There are so many variations on the “there are only two hard problems in computer programming...” joke that I’m starting to suspect that programming isn’t actually very easy. -- Nat Pryce |
Tested on MacOS 14, Windows 11, Ubuntu 22.04.3. Approved |
Functionally this looks good, and the naming and placement seem sensible to me! I've asked for @bkunda's signoff on the latter and I have one suggestion for a different icon we could use (the tuning fork that's used for "Concert pitch"), but we can save that for a part 2. |
@rpatters1 I'll merge this PR right now. After some discussion today, we decided that we might want to make some further tweaks how and where this option is presented; see #25033. The exact design is still in progress, but we'll ping you when it's ready, in case you would like to implement that part as well. Thanks! |
I'm up for doing the implementation. If we are using a new icon, I'd prefer someone else design it. (Graphic design is not where my talents lie.😅) |
Resolves: #15594
Supercedes: #22991, which should be closed.
Added buttons in the PianoKeyboardPanelContextMenuModel class that communicate with the PianoKeyboardController class to change a boolean variable. The aim is to address a limitation in the current implementation of MuseScore's keyboard view, which struggles with differently-tuned instruments. When users click on a key, the corresponding note used to be placed on the score as notated pitch, while the equivalent standard pitch was highlighted on the keyboard UI, leading to potential confusion.
This PR also adds a change to
Score::noteVal
so that the correct pitch is entered into the score, based on the menu option selected.